REMARKS 



Claims 1-2, 4-20, 30-41 and 48-49 and 51-79 are pending in the application. 
Reconsideration is respectfully requested in light of the following remarks. 

Section 102(e) Rejection : 

The Examiner rejected claims 1, 2, 4-13, 15, 17-20, 30-37, 39, 48, 49, 51-59, 61, 
63, 65-74, 76 and 78 under 35 U.S.C. § 102(e) as being anticipated by Weisman et al. 
(U.S. Publication 2002/0112058) (hereinafter "Weisman"). Applicants respectfully 
traverse this rejection for at least the reasons below. 

Regarding claim 1, Weisman fails to disclose that each of the plurality of peer 
nodes is further configured to access another of the plurality of peer nodes on the 
network using the unique peer identifier of the other peer node, wherein the peer 
node does not use a network address of the other peer node to access the other peer 
node . The Examiner cites paragraphs 863-904 of Weisman. However, the cited passage 
does not describe a peer node accessing another peer node using the unique peer 
identifier of the other peer node, wherein the peer node does not use a network address of 
the other peer node to access the other peer node. Instead, this passage describes the 
contents of the NOTIFY multicast message that a device broadcasts when added to the 
network. 

Weisman teaches that to access another device, messages are sent to the device's 
control URL, which is a combination of the network URL of the device and a unique 
identifier for the particular target service on the device. Specifically, Weisman teaches 
that a service's control URL includes the path to the device, the UDN of the device, the 
service ID and a randomly generated string (Weisman, paragraphs 122, 130-137, 815, 
and 1 148 - 1 150). Since a device's control URL is not independent of, and clearly uses, 
the network address of the device, Weisman fails to teach a peer node accessing another 
peer node using the unique peer identifier of the other peer node, wherein the peer node 



10/055,666 (5681-07700/P7116) 



2 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



does not use a network address of the other peer node to access the other peer node. 

In the response to arguments, the Examiner cites paragraphs 45, 122, 131-137, 
183 and 376 of Weisman and describes how Weisman's Web Server invokes an 
automation proxy for a service to cause the service to execute a control request. The 
Examiner states Weisman's device host API sets up control URL's of hosted devices to 
point to the Web Server. The Examiner further describes how Weisman's system format 
the URL and uuid that make up the address used to invoke control requests on the service 
object. 

However, the Examiner's remarks actually support Applicants' argument. 

The Examiner states that "Weisman discloses the Device Host API sets up the control 
URLs of hosted devices 108-110 to point to the Web Server, when the Web Server 
receives an HTTP request with one of the hosted devices ' control URLs, the Web Server 
invoke[s] the Automation Proxy for the service to execute the control request" (italics, 
added). Thus, the Examiner states that the URL a hosted device is used to access a 
hosted device via the Web Server on the same machine as the hosted device. Thus, in 
Weisman's system a network address (URL) is used when one peer is accessing another. 
The fact that Weisman's system also includes other information, such as the uuid does 
not change the fact that a network address is also used. 

Anticipation requires the presence in a single prior art reference disclosure of each 
and every limitation of the claimed invention, arranged as in the claim . M.P.E.P 2131; 
Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 
485 (Fed. Cir. 1984). The identical invention must be shown in as complete detail as is 
contained in the claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). As discussed above, Weisman fails to disclose where each of the plurality of 
peer nodes is further configured to access another of the plurality of peer nodes on the 
network using the unique peer identifier of the other peer node, wherein the peer node 
does not use a network address of the other peer node to access the other peer node . 
Therefore, Weisman cannot be said to anticipate claim 1 . 
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Thus, for at least the reasons above, the rejection of claim 1 is not supported by 
the cited art and removal thereof is respectfully requested. Similar remarks apply to 
claims 30, 48 and 66. 

Regarding claim 2, Weisman fails to disclose where each of the plurality of peer 
nodes is further configured to bind a peer identifier corresponding to the particular peer 
node to the network address of the particular peer node . The Examiner cites paragraphs 
181-124 of Weisman. The cited passage describes the addressing within Universal Plug- 
n-Play (UPnP) networking. Weisman teaches that a device may use an automatic IP 
addressing facility to obtain an address. However, the cited passage does not mention 
any peer nodes configured to bind a peer identifier corresponding to the particular peer 
node to the network address of the particular peer node. Instead, the cited passage only 
describes how a peer node may automatically obtain, such as via DHCP, an IP address. 
Weisman does not describe any peer node binding a peer identifier to a network address 
of a particular peer node. 

In the response to arguments, the Examiner cites paragraphs 833 - 837 of 
Weisman referring to Weisman's mapping of a device's DNS name to its IP address. 
However, the cited passages make no mention of a peer node binding a peer identifier of 
another peer node to the network address of the other peer node. Instead, Weisman 
describes how a computer that needs to contrast a device may use a DNS query to 
discover the devices IP address. Merely discovering an IP address of another device 
cannot be considered binding a peer identifier to a network address. Weisman states that 
the DNS mappings are used to ensure that the device can still be found even when the IP 
address changes (Weisman, paragraphs 834 - 835). Thus, Weisman teaches that a 
computer should lookup IP addresses using a DNS server specifically because IP address 
may change and the devices name can be used to lookup a changed IP address. 
Weisman's peers clearly do not bind network address to peer identifiers. 

Thus, the rejection of claim 2 is not supported by the cited art and removal thereof 
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is respectfully requested. Similar remarks also apply to claims 31,49 and 67. 



Regarding claim 5, Weisman fails to disclose wherein, to access the other peer 
node, the unique peer identifier of the other peer node is configured to be mapped to one 
of the one or more network interfaces of the other peer node . The Examiner cites 
paragraphs 7 and 63 of Weisman. However, neither of these paragraphs describes a peer 
identifier being mapped to a network interface of the other peer node. Instead, paragraph 
7 describes a device hosting framework that listens for control requests and translates 
control requests into calls to the service objects' programming interfaces (e.g. IDispatch 
interfaces). Paragraph 63 describes that service interfaces are written in UTL in service 
descriptions and how a hosted device provides a COM object that exposes the service's 
interface. Thus, the Examiner has failed to cite any portion of Weisman that discloses 
that the unique peer identifier of the other peer node is configured to be mapped to one of 
the one or more network interfaces of the other peer node . Moreover, nowhere does 
Weisman describe that a service's UDN, which the Examiner equates to the unique peer 
identifier Applicants' claims, is configured to be mapped to a network interface of a peer 
node. 

In the response to arguments, the Examiner cites paragraphs 36, 37, 67 and 67 of 
Weisman. The Examiner argues that Weisman's system translates control requests into 
calls to a service's dispatch interfaces. However, translating control requests into calls to 
the service objects' programming interfaces (e.g. IDispatch interfaces) does not disclose a 
unique peer identifier of a peer node configured to be mapped to a network interface of 
the peer node. A programming interface is not a network interface. Weisman teaches 
that the Device Host listens for and receives control requests and then locates and calls 
the dispatch interface for the hosted service. Weisman describes a hosted device as a 
software module that executes on the same machine as the Device Host. Thus, the 
translation referred to by the Examiner clearly involves the Device Host 
programmatically invoking the service interface of a hosted device. The Device Host 
does not translate the control into a network interface nor does it map a UDN to a 
network interface. 
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Thus, the rejection of claim 5 is not supported by the cited art and removal thereof 
is respectfully requested. Similar remarks also apply to claim 52. 

Regarding claim 8, Weisman fails to disclose wherein each of the plurality of peer 
nodes is assigned a different unique peer identifier in accordance with the peer-to-peer 
platform for each of the one or more peer groups in which the peer node is a member 
peer. The Examiner refers to Weisman's container identifier, citing paragraphs 85, 105 
and 489. However, Weisman only teaches that a container is a string that identifies the 
group to which the device belongs and that all devices with the same container identifier 
will be hosted in the same process. Nowhere does Weisman mention that each peer node 
is assigned a different unique peer identifier for each of the peer groups in which the peer 
node is a member peer. Weisman merely states that a container identifier identifies the 
group to which a device belongs. Thus, Weisman clearly fails to disclose wherein each 
of the plurality of peer nodes is assigned a different unique peer identifier in accordance 
with the peer-to-peer platform for each of the one or more peer groups in which the peer 
node is a member peer. 

In the response to arguments, the Examiner cites paragraphs 1513 and 1539 of 
Weisman and refers to Weisman's event subscription process. Weisman teaches that a 
service may publish event messages to interested control points, called subscribers 
(paragraph 1497). The Examiner refers to the fact that if a subscription expires, the 
subscription identifier becomes invalid and the control point sends a subscription 
message to get a new subscription identifier. First of all, Weisman's subscription 
identifiers have nothing to do with the container identifiers that the Examiner relies upon 
in the rejection of claim 8. Furthermore, the fact that each subscriber is provided with a 
unique subscription identifier has no relevance to a peer node being assigned a different 
unique peer identifier for each peer group in which the peer node is a member. 
Weisman's event publishing does not have anything to do with peer group membership. 

Therefore, the rejection of claim 8 is not supported by the cited art and removal 
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thereof is respectfully requested. Similar remarks also apply to claims 55 and 70. 

Section 103(a) Rejection : 

The Examiner rejected claims 14, 16, 38, 40, 41, 60, 62, 64, 75, 77 and 79 under 
35 U.S.C. § 103(a) as being unpatentable over Weisman in view of Ferguson et al. (U.S. 
Patent 6,490,618) (hereinafter "Ferguson"). Applicants respectfully traverse this 
rejection for at least the reasons presented above regarding the respective independent 
claims. Applicants respectfully traverse this rejection for at least the reasons presented 
above regarding the respective independent claims. 

Regarding both the § 102 and § 103 rejections, Applicants also assert that 
numerous ones of the dependent claims recite further distinctions over the cited art. 
However, since the rejection has been shown to be unsupported for the independent 
claims, a further discussion of the dependent claims is not necessary at this time. 

Double Patenting Rejection : 

The Examiner rejected claims 1-20, 30-41 and 48-79 under the judiciary created 
doctrine of obviousness-type double patenting as being unpatentable over claims of U.S. 
Patent No. 7,065,579. Applicants traverse this rejection on the grounds that the Examiner 
has not stated a proper prima facie rejection. 

The Examiner supports this rejection by stating that "the applications are claiming 
common subject matter" and listing three claim terms that the Examiner asserts are 
common to both the instant application and the '579 patent. The Examiner also states 
that the '679 patent does not claim the service layer as in the instant application, but 
asserts that it would have been obvious "that the mechanism for accessing services of 
[the] '579 patent is ... similar in functionality to the service layer of the instant 
application." However, stating that the applications claim "common subject mater" and 
similar functionality is not a proper reason for holding the claims of the present 
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application obvious from the claims of the listed applications. The Examiner's assertions 
are completely conclusory. 

According to MPEP 804.II.B.1, "the analysis employed in an obviousness-type 
double patenting determination parallels the guidelines for a 35 U.S.C. 103(a) rejection." 
This section of the MPEP also states that the same "factual inquires . . . that are applied 
for establishing a background for determining obviousness under 35 U.S.C. 103(a) are 
employed when making an obviousness-type double patenting analysis." MPEP 
804.II.B.1 also states that the Examiner should list the differences between each rejected 
claim and the claims of the other patent/application, and for each difference the Examiner 
should give the reasons why a person of ordinary skill in the art would conclude that the 
invention defined in the claim is an obvious variation of the invention defined in a claim 
of the other patent/application. 

Simply stating that the instant application and the '579 patent claim "common 
subject matter" and are "similar in functionality" is not a valid reason why a person of 
ordinary skill in the art would conclude that the invention defined in each claim is an 
obvious variation of the invention defined in a claim of the other patent/application. Nor 
has the Examiner specifically addressed each difference of each claim of the present 
application compared to the claims of the other applications. Instead, the Examiner 
improperly lumped all the claims together and did not address each specific difference. 
The Examiner clearly has not met the requirements stated in MPEP 804.II.B.1 to 
establish a prima facie obviousness-type double patenting rejection. Accordingly, 
Applicants respectfully request removal of the double patenting rejection of claims 1-20, 
30-41 and 48-79. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and prompt notice 
to that effect is respectfully requested. 

If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501505/5681- 
07700/RCK. 

Also enclosed herewith are the following items: 
I I Return Receipt Postcard 
I I Petition for Extension of Time 
O Notice of Change of Address 
□ Other: 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
ATTORNEY FOR APPLICANT(S) 

Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: December 15, 2006 



10/055,666 (5681-07700/P7116) 



9 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



